Today, many applications are web accessible and web enabled. These types of applications are commonly referred to as web services. Web services reside on the Internet and allow client applications to access them and obtain information. Web services utilize several standards, such as Simple Object Access Protocol (SOAP), eXtensible Mark-up Language (XML), Web Services Description Language (WSDL), Universal Description Discovery and Integration (UDDI), and the like. These standards provide the mechanisms for tagging data, transferring the data, and identifying the web services. They also allow web services to operate independent of any specific operating system or protocol.
Typically, web services do not provide a graphical user interface (GUI) to the user. Rather, web services provide a programmatic interface over a network, such as the Internet, that allows organizations to share business logic, data, and processes. Thus, organizations can use web services to communicate data to clients without requiring the organizations to understand each client's information technology system.
Client applications that access a web service need to invoke the web service. The web service is invoked by inserting (also commonly referred to as hard coding) a Universal Resource Locator (URL) into the code for the client application. When the client application executes, this hard coded URL is used to invoke the web service over the Internet.
Unfortunately, over time, the location (i.e., URL) of a web service may change. When this occurs, the client application will be unable to access the web service and will, therefore, not operate properly. In addition, this hard coding makes it difficult to scale up (add servers) to support increased demands on the web service. Thus, until now, there has not been a satisfactory solution that allows a web service to re-locate without impacting the code of the client application that accesses the web service.